refactor : 모듈 service, service-api로 분리#20
Merged
DongHyeonka merged 2 commits intoSynapsesa:developfrom Aug 12, 2025
Merged
Conversation
- 하나의 도메인을 dto(event, command)와 분리하여 느슨한 결합을 유지 - Kafka를 이용한 이벤트 발행 인프라 및 초기 설정 적용 - 트랜잭셔널 아웃박스 패턴 적용을 통해 데이터 정합성 보장(즉 최소한 한 번 이상 전송을 보장하기 때문에 소비자 측에서 멱등성만 구현해주면 됩니다.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
개요
본 PR은 프로젝트 초기 기술 스택을 설정하고, 향후 기능 확장에 유연하게 대응할 수 있는 마이크로서비스 아키텍처를 구축하는 것을 목표로 합니다.
주요 변경 사항은 다음과 같습니다.
상세 설계 내용 및 결정 이유
문제점 : 서비스 간의 의존성이 높으면 한 서비스의 내부 구현 변경이 다른 서비스에 영향을 미쳐 유지보수가 어렵고 빌드 시간 또한 길어집니다.
해결책 : 도메인 모듈을 service-api와 service로 분리하였습니다. 이를 통해서 각 서비스는 상대방의 구체적인 구현을 알 필요가 없습니다. 약속된 명세서 (service-api)에만 의존하여 서비스 간의 결합도를 낮출 수 있게 되었습니다.
문제점 : 마이크로 서비스에서 동기식(REST api) 호출 방식은 특정 서비스의 응답이 지연 또는 장애가 발생했을 때 해당 요청을 보낸 서비스까지 함께 장애가 전파가 되는 연쇄 장애에 취약합니다.
해결책 : 보통 이를 서킷 브레이커로 해결하지만 비동기적 통신으로 마이크로 서비스끼리의 통신에서의 문제점을 다르게 해결할 수 있게 됩니다. 그렇다고 서킷 브레이커가 불필요한 것은 아닙니다. 이의 역할이 다른 곳으로 이동하게 됩니다. 추후 나중에 도입하게 될 서킷 브레이커는 동기 통신 지점이 있는 곳이면 필요할 가능성을 열어두고 개발할 계획입니다.
문제점 : MSA 환경에서 DB 업데이트와 메시지 발행을 하나의 원자적인 작업으로 처리하기 어렵습니다. 예를 들면 DB 트랜잭션은 성공하였지만 이벤트 발행을 실패 또는 어떠한 이유로 발행이 제대로 되지 않으면 시스템은 데이터 불일치 상태에 빠질 수 있습니다.
해결책 : 이 문제를 해결하기 위해 트랜잭셔널 아웃박스 패턴을 적용했습니다. 특히, CDC(Change Data Capture) 기반의 트랜잭셔널 아웃박스 패턴을 지원하는 라이브러리를 채택하여 안정성을 높였습니다. 비즈니스 로직 처리와 발행할 이벤트를 outbox 테이블에 저장하는 과정을 하나의 로컬 트랜잭션으로 묶었습니다. 그리고 별도의 cdc 서비스가 이 outbox 테이블을 감지하여 이벤트를 안정적으로 발행함으로써 메시지 전달은 최소 한번을 보장합니다. 즉 개발자가 신경을 써야 하는 부분은 컨슈머의 멱등성만 잘 보장한다면 데이터 불일치 문제를 해결할 수 있습니다.
다음 할 일